Work Request Manager API

(1 review)

Test Cases

The tables below describe suggested test cases.

Use these test cases in conjunction with the WRM Trigger API for complete end-to end-testing.

Work Request end-to-end - Simple
Work Request end-to-end - Exceptions
Appointments and scheduling
Negative scenarios

Work Request end-to-end - Simple

Follow the test cases outlined below to test the end-to-end workflow of a work request.

Test case		API	Suggested test case description	Expected result Work Supplier	Expected result Work Requestor
1.	Create a Work Request	Trigger	Acting as the Work Requestor, use the Trigger API to initiate a CreateTask. The Trigger API creates, allocates and sends the task to the Work Supplier and changes the task state to Allocation and substate to Sent.	Receive a CreateTaskNotify from the WRM API.	Receive an HTTP success response (200) from the Trigger API Receive a CreateTaskNotify from the WRM API Receive a SendTaskNotify from the WRM API.
2.	Accept a Work Request	WRM	As the Work Supplier, use the WRM API to send an AcceptTaskEvent to the WRM.	Receive an AcceptTaskNotify from the WRM API.	Receive an AcceptTaskNotify from the WRM API.
3.	Update a Worker Contact	WRM	As the Work Supplier, use the WRM API to send an UpdateTaskActivityWorkerEvent.	Receive an HTTP success response (200) from the WRM API. No payload is returned.	Receive an UpdateTaskActivityWorkerNotify from the WRM API.
4.	Send a status update - Scheduled	WRM	As the Work Supplier, use the WRM API to send an UpdateTaskActivityStatusEvent with the status category Open and state Scheduled.	Receive an UpdateTaskActivityStatusNotify from the WRM API.	Receive an UpdateTaskActivityStatusNotify from the WRM API.
5.	Send a status update - Onsite	WRM	As the Work Supplier, use the WRM API to send an UpdateTaskActivityStatusEvent with the status category Active and state OnSite.	Receive an UpdateTaskActivityStatusNotify from the WRM API.	Receive an UpdateTaskActivityStatusNotify from the WRM API.
6.	Send a status update - Practical Completion	WRM	As the Work Supplier, use the WRM API to send an UpdateTaskActivityStatusEvent with the status category Active and state PracticalCompletion.	Receive an UpdateTaskActivityStatusNotify from the WRM API.	Receive an UpdateTaskActivityStatusNotify from the WRM API.
7.	Receive an Activity Update - Additional Information	Trigger	Acting as the Work Requestor, use the Trigger API to send an UpdateTaskAdditionalInfos to test the receipt of additional information.	Receive an UpdateTaskAdditionalInfoNotify from the WRM API.	Receive an HTTP success response (200) from the Trigger API.
8.	Send an Activity Update - Additional Information	WRM	As the Work Supplier, use the WRM API to send an UpdateTaskAdditionalInfosEvent to the Work Requestor.	Receive an HTTP success response (200) from the WRM API. No payload is returned.	Receive an UpdateTaskAdditionalInfoNotify from the WRM API.
9.	Update Outcomes	WRM	As the Work Supplier, use the WRM API to send an UpdateTaskActivityOutcomesEvent to the Work Requestor.	Receive an HTTP success response (200) from the Trigger API. No payload is returned.	Receive an UpdateTaskActivityOutcomesNotify from the WRM API.
10.	Close an Activity	WRM	As the Work Supplier, use the WRM API to send the CloseTaskActivityEvent. Ensure the status category is set to Closed and the state Complete.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.

Work Request end-to-end - Exceptions

Follow the test cases outlined below to test the common exception scenarios associated with managing a work request.

For each of these tests:

Use the Trigger API to initiate a CreateTask.
Use the WRM API to send an AcceptTaskEvent to the WRM.
Ensure the activity is in the correct state for the test to succeed as described in the individual test cases.

For:

the closure scenarios, activities have the workSupplierAllowedToCancel flag set to either true or false
activities such as Scope, InsideInstall or FibreCPE that have the workSupplierAllowedToCancel flag set to false, use the Trigger API to initiate a CancelTask before testing
activities such as BuildToETP, OHUG, Infill, OutsideBoundaryReinstatement that have the workSupplierAllowedToCancel flag set to true, do not initate a CancelTask before testing.

It is suggested that you test all scenarios.

Test Case		API	Suggested test case description	Expected result Work Supplier	Expected result Work Requestor
1.	Create a Work Request	Trigger	Acting as a Work Requestor, use the Trigger API to initiate a CreateTask	Receive a CreateTaskNotify from the Trigger API	Receive a CreateTaskNotify from the Trigger API Receive a SendTaskNotify from the Trigger API.
2.	Reject a Work Request	WRM	As the Work Supplier, Use the WRM API to send a RejectTaskEvent to the WRM. Note: The reason attribute must be included.	Receive an HTTP success response. (204). No payload is returned.	Receive a RejectTaskNotify from the WRM API. The task state is unallocated.
3.	Put an Activity on Hold	WRM	Use the PutOnHoldTaskActivityEvent to put an activity on hold. The status category is OnHold and the state OnHold.	Receive a PutOnHoldTaskActivityNotify from the WRM API.	Receive a PutOnHoldTaskActivityNotify from the WRM API.
4.	Receive a Task Cancellation	Trigger	Acting as a Work Requestor, use the Trigger API to initiate a CancelTask.	Receive a CancelTaskNotify from the Trigger API.	Receive a CancelTaskNotify from the Trigger API.
5.	Close an Activity as incomplete where the workSupplierAllowedToCancel flag is set to false	WRM	As the Work Supplier, use the WRM API to send the CloseTaskActivityEvent. Ensure the status is set to Incomplete, the status category Closed and the state Incomplete. Note: Use the Trigger API to initiate a CancelTask.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.
6.	Close an Activity as Cancelled where the workSupplierAllowedToCancel flag is set to false	WRM	As the Work Supplier, use the WRM API to send the CloseTaskActivityEvent. Ensure the status category is set to Closed and the state Cancelled. Note: Use the Trigger API to initiate a CancelTaskEvent.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.
7.	Close an Activity as incomplete where the workSupplierAllowedToCancel flag is set to true	WRM	As the Work Supplier, use the WRM API to send the CloseTaskActivityEvent. Ensure the status category is Closed and the state Incomplete. Note: Do not initiate a CancelTaskEvent.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.
8.	Close / Cancel an Activity where the workSupplierAllowedToCancel flag is set to true	WRM	As the Work Supplier, use the WRM API to send the CloseTaskActivityEvent. Ensure the status category is set to Closed and the state Cancelled. Note: Do not initiate a CancelTaskEvent.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.	Receive a CloseTaskActivityNotify from the WRM API. If there are no other open activities the task closes, and the Work Supplier receives a CloseTaskNotify from the WRM API.

Appointments and scheduling

Follow the test cases outlined below to test managing schedules and appointments.

For each of these tests:

Use the Trigger API to initiate a CreateTask. Ensure the Task created is one that requires an appointment.
Use the WRM API to send an AcceptTaskEvent to the WRM.
Perform any required actions in your internal systems, for example checking for available appointment slots.

Test Case	API	Suggested Test Case description	Expected result Work Supplier	Expected result Work Requestor
1.	Cancel an Appointment	WRM	As the Work Supplier use the Appointment Management DELETE /appointments/{bookingId} command to cancel an appointment.	Receive an HTTP success response (204). No payload is returned.	The work requestor does not receive a notification.
2.	Reschedule an Appointment	WRM	As the Work Supplier, use the Appointment Management PUT /appointments/{bookingId} command to reschedule an appointment. Ensure the following attributes are populated: Existing Appointment Booking Id Reschedule Type (Commitment Type) Schedule Id Requested Start Date Time Request End Date Time Number of Units to release from original appointment.	Receive an HTTP success response. (204). No payload is returned.	The work requestor does not receive a notification.
3.	Update a Schedule	WRM	As the Work Supplier, use the WRM API to send the UpdateTaskActivityScheduleByWorkSupplierEvent.	Receive an HTTP success response. (204). No payload is returned.	Receive an UpdateTaskActivityScheduleByWorkRequestorNotify from the WRM API.

Test Case

API

Suggested Test Case description

Expected result Work Supplier

Expected result Work Requestor

Cancel an Appointment

WRM

As the Work Supplier use the Appointment Management DELETE /appointments/{bookingId} command to cancel an appointment.

Receive an HTTP success response (204). No payload is returned.

The work requestor does not receive a notification.

Reschedule an Appointment

WRM

As the Work Supplier, use the Appointment Management PUT /appointments/{bookingId} command to reschedule an appointment. Ensure the following attributes are populated:

Existing Appointment Booking Id
Reschedule Type (Commitment Type)
Schedule Id
Requested Start Date Time
Request End Date Time
Number of Units to release from original appointment.

Receive an HTTP success response. (204). No payload is returned.

The work requestor does not receive a notification.

Update a Schedule

WRM

As the Work Supplier, use the WRM API to send the UpdateTaskActivityScheduleByWorkSupplierEvent.

Receive an HTTP success response. (204). No payload is returned.

Receive an UpdateTaskActivityScheduleByWorkRequestorNotify from the WRM API.

Negative scenarios

Follow the test cases outlined below to test negative scenarios associated with managing a work request.

For each of these tests:

Use the Trigger API to initiate a CreateTask.
Ensure the required prerequisites have been met as described in the individual test cases.

Test Case		API	Suggested Test Case description	Expected result Work Supplier	Expected result Work Requestor
1.	Reject a Work Request with an active activity task	WRM	As the Work Supplier, use the WRM API to send a RejectTaskEvent to the WRM. Ensure the task has an associated activity which is or has been active.	Receive an exception response from the WRM with the error code 1073. The response includes the transaction id and an exception message.	The work requestor does not receive a notification.
2.	Put an Activity on Hold / Use an invalid reason code.	WRM	As the Work Supplier, use the WRM API to take an Activity that has a status of Active / PracticalCompletion and update the status to Active / Onsite.	Receive an exception response from the WRM with the error code 3058. The response includes the transaction id and an exception message.	The Work Requestor does not receive a notification.
3.	Send a status update after Practical Completion	WRM	As the Work Supplier, use the WRM API to take an Activity that has a status of Active / PracticalCompletion and update the status to Active / OnSite.	Receive an exception response from the WRM with the error code 30313. The response includes the transaction id and a message.	The Work Requestor does not receive a notification.
4.	Close an Activity in an Open State as Closed / Complete	WRM	As the Work Supplier, use the WRM API to take an Activity that has a status of Active / PracticalCompletion and update the status to Active / OnSite.	Receive an exception response from the WRM with the error code 3065. The response includes the transaction id and an exception message.	The Work Requestor does not receive a notification.
5.	Close an Activity as incomplete where the workSupplierAllowedToCancel flag is set to false.	WRM	Take an activity where the workSupplierAllowedToCancel flag is set to false, and use the WRM API to send the CloseTaskActivityEvent. Ensure the status category is set to Closed and the state Cancelled. Note: Do not use the Trigger API to initiate a CancelTask.	Receive an exception response from the WRM with the error code 3065. The response includes the transaction id and a message.	The Work Requestor does not receive a notification.
6.	Update a closed Activity	WRM	As the Work Supplier, use the WRM API to take an activity that is in a Closed status and send a status update.	Receive an exception response from the WRM with the error code 30314. The response includes the transaction id and an exception message.	The Work Requestor does not receive a notification.

Test Cases

Work Request end-to-end - Simple

Work Request end-to-end - Exceptions

Appointments and scheduling

Negative scenarios

Reviews